FIG. 1 shows an exemplary network structure of an Evolved Universal Mobile Telecommunications System (E-UMTS) as a mobile communication system to which a related art and the present invention are applied. The E-UMTS system is a system that has evolved from the existing UMTS system, and its standardization work is currently being performed by the 3GPP standards organization. The E-UMTS system can also be referred to as a LTE (Long-Term Evolution) system.
The E-UMTS network can roughly be divided into an E-UTRAN and a Core Network (CN). The E-UTRAN is generally comprised of a terminal (i.e., User Equipment (UE)), a base station (i.e., eNode B), a serving gateway (S-GW) that is located at an end of the E-UMTS network and connects with one or more external networks, and a Mobility Management Entity (MME) that performs mobility management functions for a mobile terminal. One eNode B may have one or more cells.
FIG. 2 shows an exemplary architecture of a radio interface protocol between a terminal and an E-UTRAN according to the 3GPP radio access network standard. The radio interface protocol as shown in FIG. 2 is horizontally comprised of a physical layer, a data link layer, and a network layer, and vertically comprised of a user plane for transmitting user data and a control plane for transferring control signaling. The protocol layer in FIG. 2 may be divided into L1 (Layer 1), L2 (Layer 2), and L3 (Layer 3) based upon the lower three layers of the Open System Interconnection (OSI) standards model that is widely known in the field of communication systems.
Hereinafter, descriptions of particular layers of the radio protocol control plane of FIG. 2 and of the radio protocol user plane of FIG. 3 will be given in detail.
The physical layer (Layer 1) uses a physical channel to provide an information transfer service to a higher layer. The physical layer is connected with a medium access control (MAC) layer located thereabove via a transport channel, and data is transferred between the physical layer and the MAC layer via the transport channel. Also, between respectively different physical layers, namely, between the respective physical layers of the transmitting side (transmitter) and the receiving side (receiver), data is transferred via a physical channel.
The Medium Access Control (MAC) layer of Layer 2 provides services to a radio link control (RLC) layer (which is a higher layer) via a logical channel. The RLC layer of Layer 2 supports the transmission of data with reliability. It should be noted that if the RLC functions are implemented in and performed by the MAC layer, the RLC layer itself may not need to exist. The PDCP layer of Layer 2 performs a header compression function that reduces unnecessary control information such that data being transmitted by employing Internet Protocol (IP) packets, such as IPv4 or IPv6, can be efficiently sent over a radio interface that has a relatively small bandwidth.
The Radio Resource Control (RRC) layer located at the lowermost portion of Layer 3 is only defined in the control plane, and handles the control of logical channels, transport channels, and physical channels with respect to the configuration, reconfiguration and release of radio bearers (RB). Here, the RB refers to a service that is provided by Layer 2 for data transfer between the mobile terminal and the UTRAN.
Next, description of a Medium Access Control (MAC) Protocol Data Unit (PDU) used in a MAC entity will be given in more detail. FIG. 4 shows a general Protocol Data Unit (PDU) format used in a MAC entity. Referring to FIG. 4, the Logical Channel ID (LCID) field identifies a logical channel instance of a corresponding MAC SDU, and the Length (L) field indicates a length of the corresponding MAC SDU in bytes. The Extension (E) field indicates whether or not more fields are present in the MAC header. As shown in FIG. 5, in a process of generating the MAC PDU, if a size of the corresponding MAC SDU or MAC Control Element is less than or equal to 127, 7-bits L field is used. If not, a MAC sub-header including 15-bits L field is used. And, a MAC sub-header as shown in FIG. 6 is used for a MAC sub-header of the MAC SDU included in the MAC PDU or a fixed size MAC Control Element.
Next, descriptions of each field used in FIGS. 4, 5 and 6 will be given in more detail. First, the LCID field indicates the type of logical channel data of the corresponding MAC SDU or the type of data contained in the corresponding MAC Control Element (MAC CE). The E field indicates whether or not another MAC sub-header is subsequent to the current MAC sub-header. The Format (F) field indicates a length of the subsequent L field. The Reserved (R) field denotes a reserved bit and is an unused bit.
In general, a base station notifies a size of MAC PDU to a terminal via the PDCCH, which is a control channel of the physical layer, each time the MAC PDU is transmitted. That is, since the size of the MAC PDU transmitted via the PDCCH is known, there is no need to include any information indicating the overall size of the MAC PDU in the MAC PDU.
However, there is a limit in an amount of information transmitted via the PDCCH. That is, a size of the MAC PDU among the information transmitted via the PDCCH, i.e., the number of bits of information indicating a size of a Transport Block (TB) is limited. For instance, if a maximum size of the MAC PDU is set to 2000 bytes, 11 bit is needed to indicate the size of the MAC PDU in 1-byte unit. In this case, if the number of bits actually being used is 6, the size of the MAC PDU would be represented in 32-byte unit.
Meanwhile, an upper layer, specifically, the RLC generates MAC SDU for transmission into a size requested by the MAC entity. However, due to a small amount of data actually being stored in the RLC, if MAC SDU of a smaller size than that requested by the MAC is generated, the MAC entity generates MAC PDU by adding a padding bit thereto.
However, the related art may have the following problems.
FIG. 7 shows exemplary structure of related art MAC PDU. Referring to FIG. 7, it is assumed that a size of the MAC PDU, i.e., a size of the Transport Block (TB) is N+M+1 octet. In the related art, a MAC sub-header without having the L field is used for the last MAC SDU. Here, the presence of 1 octet would be ambiguous depending on the size of the last MAC SDU.
For instance, in FIGS. 7(a) and 7(b), it is assumed that RLC PDU 1 through RLC PDU N−1 are the same in size, and the last RLC PDU (i.e., RLC PDU N) in FIG. 7(b) has a smaller size by 1, as compared to that in FIG. 7(a). In FIG. 7(b), it is assumed that a total size of MAC sub-headers and associated MAC SDU (RLC PDU) or MAC Control Element and a size of the transport block are the same. Here, if the size of the RLC PDU N is reduced by 1, it means 1 byte space is generated in the MAC PDU. If the transmitting side MAC entity does not indicate an existence of 1 byte padding in the last of the MAC PDU, the receiving side MAC entity would not be able to distinguish the two cases as shown in FIGS. 7(a) and 7(b) from each other. In addition, the receiving side MAC entity would decode the two cases to the same RLC PDUs.
In addition, if an additional header is added to indicate the existence of padding in the last of the MAC PDU in FIG. 7, a problem shown in FIG. 8 would occur. That is, in FIG. 7(b), in order to include a MAC sub-header for padding, a MAC sub-header being included right before the MAC sub-header should include the L field. This assumes, as shown in FIG. 8(b), that the size of the RLC PDU N (i.e., the MAC SDU being included in the last) should be reduced. Further, padding is not needed in this case. That is, according to the related art, if there is 1-byte or 2-byte space in the MAC PDU, a problem in generating the MAC PDU would occur.